Telecommunications services are complex and, as more services become available, the user access to these services becomes more unmanageable without user friendly assistance. Experiments by telecommunications service providers have shown that if the user interface to network services can be simplified, it is likely that users may access and use these new more complex services more often. One way to simplify access to these services is to provide the user with a screen-assisted interface to the services.
One such experiment conducted by Bell Communications Research provided a more usable access to network voice services via advanced Customer Premises Equipment (CPE) with a screen display and context-sensitive soft keys. This interface enabled the network to support screen-assisted management of CLASS.SM. and Custom Calling Services (CCS). The experiment was to determine if the utility and acceptability, and therefore, usage, of network services were positively affected by a screen-assisted telephone. Residential subscribers used a prototype CPE during the experiment and accessed network services using this device.
The prototype CPE provided a 7 line by 16 character liquid crystal display (LCD) as a visual interface that responds to user actions in context of the call states. The visual interface provides the users with context sensitive menus, step by step prompts, visual indicators of the services status, and a call log feature. This specific experiment demonstrated the acceptability of a screen-assisted telephone. It also indicated customer interest in acquiring such phones and helped to confirm that there is a need to make network services easier for customers to access and use. Visual access to voice services via display-based sets can improve the usability of current and future services by providing customers visual choices or options for services at appropriate times during a call or service transaction. To provide this capability in a generic way, the Analog Display Service Interface (ADSI) protocol has been developed to provide an interface between the network service features and the advanced CPE, such as visual displays and soft keys, and allows the network to support screen-based management of telephone services. The ADSI protocol has been publicly disclosed in Bellcore Technical Reference "Generic Requirements for an SPCS to Customer Premises Equipment Data Interface for Analog Display Services", TR-NWT-001273, December 1992.
The ADSI protocol defines a generic way for the CPE to communicate with the network switching equipment to access and invoke various service features. The CPE in using the ADSI protocol to access service features will have scripts that are executed based on user response to the call states. However, the network environment for implementing these advanced services comprises customers served from different central office switch types using different procedures for accessing the same features. Consequently, this means that the scripts in each CPE must be matched to the specific line, switch, and switch software requirements and updated when the switch software is updated or when the switch is changed. Therefore, embedded within the ADSI protocol is a feature download capability which allows the downloading of a service script from the network to the screen capable CPE. These service scripts stay resident in the CPE's memory and are used to create screen displays in response to network signals for accessing service features. These scripts can therefore be changed as the switch and switch software change and then downloaded in the CPE. If the scripts were built into the CPE, the customer would be faced with equipment that would become incompatible with the network as the network changes.
Service scripts for use in ADSI devices are defined in Bellcore Special Report entitled "Customer Premises Equipment Compatibility Considerations for the Analog Display Services Interface", SR-INS-002461, December 1992. Such scripts consist of a set of op.sub.-- code instructions. However, the telephone companies do not expect a programmer to write Service Scripts in the binary op.sub.-- codes as defined in DR-INS-002461. High level scripting languages are being developed for the script programmer. Appendix 2 of SR-INS-002461 illustrates scripts developed in an example high level language.
Another variation in the environment for advanced call management features in screen based telephones, in addition to the need to operate with various switch types and switch software, is that different customers have different requirements for suites of service features. Therefore, a service script to support one customer's suite of service features is going to be different than that of another customer. Consequently, there is a need to develop service scripts for various sets of features. However, to write a service script for each permutation of all feature sets becomes quite difficult as the number of features increases. Specifically, if there are m features, then there is a need for ##EQU1## service scripts. For each one new feature added there will be 2.sup.m more service scripts required. Building and maintaining these service scripts can, therefore, become quite labor intensive.
It is therefore an object of my invention to provide the telephone companies with the ability to build and maintain service scripts without having to write a separate script for each permutation of service features. It is a second object of my invention to provide an automated capability for developing and then consolidating service scripts for multiple features into a single service script for a customer and downloading the consolidated service script.